fix: expired OAuth sessions must 401 instead of silently degrading - #21
Merged
Conversation
When an OAuth session expired, authMiddleware fell through to the legacy direct-developer-key branch and passed the dead session ID to the API as if it were a key. The client got the API's "Unauthenticated." as a tool error rather than a 401, so it never learned to re-authorise - and could not recover even on reconnect. The only fix available to a user was to remove and re-add the connector. The existing 401 branch was unreachable on that path: sessionId was only set when a session had already been found. Recognise tokens shaped like session IDs we issue (64 lowercase hex from randomBytes(32); developer keys are UUIDs, so no collision) and return 401 with WWW-Authenticate pointing at the resource metadata, which is the client's cue to re-run OAuth. Sessions have a 24h TTL, so this path is hit daily by every hosted customer. Verified against a locally built server in production mode: expired-session-shaped token -> 401 + WWW-Authenticate UUID developer key -> 200, session issued, no WWW-Authenticate no auth header -> 401
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
When an OAuth session expired,
authMiddlewarefell through to the legacy direct-developer-key branch and passed the dead session ID to the Digital Samba API as if it were a key.The client therefore received the API's
"Unauthenticated."as a tool error rather than a401— so it never learned to re-authorise, and could not recover even on reconnect. The only remedy available to a user was to remove and re-add the connector.The existing 401 branch was unreachable on that path:
sessionIdwas only set when a session had already been found.Sessions have a 24h TTL (
TTL.SESSION), so every hosted customer hits this daily.Found while smoke-testing after #19/#20: reconnecting the dev connector produced
UnauthenticatedwithoauthSessions: 0and zeromcp:session:keys in Redis — the transport reconnected, but OAuth was never re-run because nothing told the client to.Change
Recognise tokens shaped like the session IDs we issue and treat them as sessions even when expired:
randomBytes(32).toString("hex")→ 64 lowercase hex, no dashesThe two shapes never collide, so legacy direct-key usage is unaffected.
Expired sessions now return 401 with
WWW-Authenticate: Bearer realm="mcp", error="invalid_token", ... resource_metadata="/.well-known/oauth-protected-resource"— the standard cue for the client to re-run OAuth itself.Verification
Against a locally built server in
NODE_ENV=production:WWW-Authenticate✅WWW-Authenticate✅7 new unit tests pin the predicate in both directions (too narrow → sessions leak into developer-key mode; too broad → legacy keys rejected).
547 tests passing (was 540). Lint and format clean.
Related, not fixed here
refreshTokenis stored on the session (src/oauth.ts) but never read — we hold a DS refresh token and let sessions die at 24h anyway. Implementing refresh would remove this expiry cliff entirely rather than just reporting it correctly. Worth a follow-up.